Method and apparatus for scalable content routing and mobility in named data networks

ABSTRACT

Various disclosed embodiments include methods, systems, and computer-readable media for named data network (NDN) inter/intra-domain mobility. A complete de-coupling of identity and addressing space is established. This provides separation of control and forwarding allowing rich policy based routing, using SDN principles, as well as policy based global resolution. In one embodiment, the de-coupling of identity from location is achieved by a changeable forwarding label field in a header that can have nodal/domain/global scope. This disclosure provides content routing/mobility to be handled with a high degree of flexibility. This disclosure also provides mobility as a service for a component of a name space.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 14/988,419 filed on Jan. 5, 2016, now allowed, entitled “METHODAND APPARATUS FOR SCALABLE CONTENT ROUTING AND MOBILITY IN NAMED DATANETWORKS”, which is a continuation of U.S. patent application Ser. No.14/146,540, filed on Jan. 2, 2014, now U.S. Pat. No. 9,246,803, all ofwhich applications are hereby incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates generally to content routing in NamedData Networks (NDN), and more specifically to NDN Inter/Intra-DomainMobility.

BACKGROUND

The named data networking (NDN) project aims to develop a new Internetarchitecture that can capitalize on strengths—and address weaknesses—ofthe Internet's current host-based, point-to-point communicationarchitecture in order to naturally accommodate emerging patterns ofcommunication. The project studies the technical challenges that must beaddressed to validate NDN as a future Internet architecture: routingscalability, fast forwarding, trust models, network security, contentprotection and privacy, and fundamental communication theory.

The project uses end-to-end test bed deployments, simulation, andtheoretical analysis to evaluate the proposed architecture, and isdeveloping specifications and prototype implementations of NDN protocolsand applications. NDN Technical Report NDN-0001 Named Data Networking(NDN) Project is a slightly modified version of the NDN projectproposal.

Currently, there is no solution from the NDN community to handlemobility, including NDN Inter/Intra-Domain Mobility.

There is desired a solution to handle mobility, including NDNInter/Intra-Domain Mobility. Objectives include providing scalability,routing on fixed infrastructure elements, routing/forwarding stability,handling seamless mobility of consumers and producers, iterativelocation resolution, and local caching.

SUMMARY

The present disclosure provides a solution to handle mobility, includingNDN inter/intra-domain mobility by complete de-coupling of identity andaddressing space. In one aspect of the disclosure, the de-coupling ofidentity from resolution service point is achieved by providing achangeable forwarding label field in a header that hasnodal/domain/global scope. The forwarding-label also allows rich policybased routing, using SDN principles, as well as policy based globalresolution. This disclosure provides content routing/mobility, orservice dynamism to be handled with a high degree of flexibility.Mobility as a service can be handled by identifying name space thatrequires mobility service and actively registering them with thenetwork, this is indicated as a service flag in the interest message.Intra-session mobility is achieved by setting a flag in the contentresponse, this indicates all the service routers to re-resolve themobile name space.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, wherein likenumbers designate like objects, and in which:

FIG. 1 illustrates a networking system for named-data networking;

FIG. 2 illustrates a forwarding-label field introduced into a headerfacilitating inter/intra-domain mobility according to one embodiment ofthe disclosure;

FIG. 3 illustrates a seamless mobility method according to oneembodiment of the disclosure;

FIG. 4 illustrates the networking system handling seamless mobility;

FIG. 5 illustrates mobility over a name space;

FIG. 6 illustrates a diagram of a network unit which may be any devicethat transports and processes data through the network; and

FIG. 7 a diagram of network components.

DETAILED DESCRIPTION

This disclosure introduces and/or involves the following networkcomponents:

Named Entities: Could be Services/Devices/Content/Users.

Domain Controller: A local domain controller for name resolution and thefast-path table (FPT). The domain controllers also participate indistributed policy based exchange of Entity-id and Network binding. E.g.BGP can be used for this purpose.

Forwarding-Label: To leverage complete decoupling of entity-id andresolution point, the forwarding-label is temporary based on policyrequirement, hence, could be of Nodal/Domain/Global scope.

Fast-Path Table: To avoid slow-path resolution, the FPT table allowsnodal fast switching, and only the first interest packet of the flowrequires resolution. Re-resolution may be required if the resourceobject is mobile or the service is scaled or migrated.

Entity-ID: The meaning of this remains unchanged from what ICNidentifies, and any generic format such as PID can also be used. Butthis has implication on the content routing implementation as such, thisdisclosure is unaffected by this.

Mobility Service: Entities register to the network for mobility service,this creates a name:home-network binding. In addition the ICN layeractively marks the content response by setting the mobility flag, whichforces re-resolution of the named entities. In addition, the Interestcan also have the mobility service flag set for the network to handlethe Interest through the FTP and local control resolution.

The present disclosure provides a solution to handle mobility, includingNDN inter/intra-domain mobility. This is achieved by completede-coupling of identity and name resolution space which ICN allows,which is enabled in NDN. This is enabled through a “forwarding-label” inthe Interest/Content response. The forwarding-label in the Interest canbe set considering rich policy based routing e.g. using SDN principles,as well as policy based global resolution. Optionally, theforwarding-label in the response can be set to allow applications tolearn the locator information, which can be set in the subsequentinterest requests, or this overhead can be avoided.

In one embodiment, the de-coupling of name from location is achieved byintroducing a forwarding-label field in the NDN header that can havenodal/domain/global scope. The forwarding-label field could havenodal/segment scope as resolution may happen at every hop, or end of asegment, giving fine grained routing/forwarding. The scope of theforwarding-label field is a result of resolution happening at eachdomain, particularly at the entry and exit points through servicerouters. Multiple domains can agree on global scope forwarding label,and this is similar to an IP locator or MPLS label that determines anend-to-end or path segments. This allows content routing/mobility to behandled with high degree of flexibility. In a general case theforwarding-label could also encode explicit paths or sub-paths asconcatenation of named network/router elements; at the egress points ofthese sub-paths the resolution can iterate to enforce more routingpolicies.

FIG. 1 illustrates a NDN network at 100 that supports seamless mobilityaccording to the present disclosure. The system 100 may comprise aplurality of mobile nodes (MN) 110, a plurality of point of attachments(PoA) 120 providing network access to the mobile nodes 110, a pluralityof content routers (R) 130, and a plurality of interconnected domaincontrollers (AS) 140. In network 100, each entity (e.g. content portion,chunk, mobile entity, or networking element) may be uniquely identifiedby an identifier.

This disclosure achieves NDN inter/intra domain mobility whereby eachNDN header 170 is provided with forwarding locator field 180, alsoreferred to as a forwarding-label herein, as shown in FIG. 2. Each NDNheader 170 is assumed to have a distinct ID. Advantageously, thisforwarding locator field 180 enables policy at every hop and domain innetwork 100.

The local resolution for a remote content-ID is at the level of the AS140, through the associated resolution controller. There is a resolutionservice controller per AS 140. In one solution, the resolution servicecontroller of each AS 140 syncs with each other either through adistributed protocol (BGP) or rooted at a global controller, enableinter-AS connectivity; or else when device/user/service registers itbinds its name with a home-domain which is consulted for nameresolution, in this case no synchronization is required. The domainservice controller is a logical overlay across multiple domains and mayor may not be topology aware (intra- and inter-domain), and managesservice directory binding depending on the solution.

In the case where a global synchronization is assumed, the entries areas follows:

local/remote_name_object_id→network address/locator

If network binding is part of the name the entries are only local, butthe name itself identifies the home controller service, in this case theentries are only for local entities:

Local_name_object_id->network address/locator

This resolution can also be determined dynamically through flooding overthe logical overlay of resolution servers, or through structure routingbetween resolution servers, such as a tree with root resolving all theresource object ids, or by binding the resolution controller servicewith the entity ID; here, it is assumed the global reachability of theresolution controller.

If the resolution controller is topology aware, then this mapping mayexist, else it is assumed that the forwarding network has information onhow to route the Interest packet based on the forwarding label.

For local content:

local_content_id→local_Router_ID; and

For remote content:

Remote_content_id->Network-ID

Network-ID ->Traffic engineering policy (e.g. Border_router_ID)

Else, if the topology routing is distributed, the router themselvesshould be able to handle forwarding based on routing informationpopulated through a distributed control plane.

Advantageously, only the first interest will go through the slow path,once resolved a fast path table (FPT) entry is created. The FPT entry isassumed to be managed actively using soft states. For efficiency, theFPT may only be managed at the edge service routers, i.e. at the entrypoints of the network facing the use traffic. The remaining routers cando name based forwarding but based on topological IDs instead of contentIDs.

In the remote domain, the fast path table (FPT) carries local contentflow entries, and this can be populated as a result of local contentresolution. Remote content entries are done on demand.

The FPT holds two forwarding data structures, one is for short termflows to support content/service/host level resolution, and the other islong term flows to support network/router level resolution, the lattercan also be merged with the FIB in case of NDN. The need of the seconddata structure depends on if the core routers have the capability ofrouting on remote network/router ID's or not. If the domain routing islocal, then the forwarding-label is only set to local domain routingcontext.

The forwarding-label can be swapped at the intermediate destinationpoint (based on the scope defined earlier), after resolution or throughFPT look-up. The FPT is updated with new flow entries after everyresolution.

The producer's seamless mobility itself can be handled in at least twopossible ways. First, when a producer moves it can notify of any suchmovement by marking the content object with a mobility flag bit. Whenservice routers receive content with the mobility bit set, it can tryre-resolving the resource object. At this point the resolutioninfrastructure can re-resolve the resource-object-id and apply new pathpolicies, for e.g. if the producer moves from one domain to another,then completely new routing policies may have to be applied.

The domain controller (AS) 140 acts as a slow path for resolution, whena packet enters a domain controller (AS) 140 without a forwarding labelor in-direction point is reached. For example, referring to FIG. 1, aslong as Alice_dev_id moves around PoAs 120 associated with the servicerouter R7, only local updates are required.

Whenever the entity is mobile, the content response contains themobility flag which will be set, it will be unset otherwise. Thisenables the service nodes to re-resolve the entity ID.

If the service router R for Alice_dev_id, then domain level update isrequired. With home domain binding to entity ID, the foreign controllercan update the home controller about the location of the entity, withouthaving the controllers to synchronize any information.

The inter-domain update is required if Alice_dev_id moves out of thedomain.

This solution holds good both for static and mobile content.

Caching/Publishing

The role of BGP or similar protocols like MH-DHT is purely for contentresolution, unlike its role in BGP to manage the FIB. This mitigates BGPstability issue from the forwarding plane.

Dynamic content arriving into the network 100 can be locally cached formulticasting, using the content name against the content store.

Explicitly published content at the AS 140 can be resolved to access therouter R holding the content.

[0054 ] State based reverse path forwarding, or explicit resolution ofsource-id, can be used to set a bi-direction entry in the FPT.

The domain based approach allows local policy imposition both for localand remote content as well, than centralized GNRS approach which lacksthat ability.

Illustrative Example

Referring to FIG. 3 in view of FIG. 1, the following example illustratesadvantageous aspects of the present disclosure.

MN 100 labeled Alice is the producer and MN 100 labeled Bob is theconsumer.

At step 200, Alice's device (Alice_dev_id) holds content X. Alicerequests network 100 for service mobility of this content. Aliceregisters/Alice_dev_id/X to its serving PoA 120, here, PoA-3 (assume aproxy agent (PA) in each POA). The network binds a home network id tothe name, to support mobility. /Alice_dev_id/X: AS-3/RS. RS Stands forresolution service (i.e. the controller resolution service)

At step 210, PoA-3 forwards the registration to its service router 130,router R7. The service router R7 creates a local entry in its FPT:

/Alice_dev_id/X: AS-3/PoA3

Then, router R7 acknowledges PoA-3, which PoA-3 also creates a localentry in its FPT:

/Alice_dev_id/X: AS-3→/Alice_dev_id.

At step 220, the service router R7 then registers the name/Alice_dev_id/:AS-3 (aggregated for scalability) to its domaincontroller 140, AS-3, which creates mapping in its service routingtable:

/Alice_dev_id/:AS-3→AS-3

The network association with name could be based on any logical ID, butit has to map to an AS level routable network name, and it is assumedthe two are same here.

The controllers resolve these bindings with other controllers on-demand.

If the controllers are topology aware, they map further fromAS_ID→Border-locator based on certain routing policies.

Router R7 assumes a logical separation between container and thecontent.

The domain controllers 140 sync these bindings with other domaincontrollers 140. The controllers 140 are topology aware, hence, they canmap further from AS_ID→Border-locator.

At step 240, Bob expresses interest for Alice contentAlice_dev_id/X:AS-3/RS.

Bob's MN is configured with a default “/” prefix in its FIB for next hopas /PoA-1 (could further resolve to another locator ID). This is set asits forwarding-label.

The interest is then forwarded to the PoA 120 servicing Bob's MN, PoA-1.PoA-1 for its uplink can avoid any resolution and forward it directly toserving router R1.

At step 250, at router R1, if the flow entry for /Alice_dev_id/X:AS-3/RSis not there, then at step 260 the router R1 resolves through theserving domain controller, AS-1.

At step 270, the domain controller AS-1 returns the /Alice_dev_id/:AS3mapping to AS-3, and AS-3 mapping to multiple router-IDs, only if thecontroller is topology aware.

It is assumed the router-IDs reachability through FIB, as these entriesare persistent, and long lived. The interest at router R1 can bemulticasted based on the controller AS-3 response. The forwarding-labelis now swapped for the border node labels and multicasted into thenetwork 100. These steps iterate at each domain, until the edge routersR of AS-3 are reached.

At step 280, at the AS-3 edge routers, the local domain resolutionshould result in locating the service router R7 serving Alice's MN.

The forwarding-label is set to router R7, when R7 receives it, and has aFPT entry for PoA-3 which has the entry for /Alice_dev_id/X, similarforwarding happens at /PoA-3. Content Alice_dev_id/X at the Alice MN isthen made available at steps 290 and 300.

When Alice_dev_id moves within her home domain, the current attachmentpoint (Router) updates the local controller about her location. So anynew session can resolved to the new location.

When Alice_dev_id moves outside her home domain, when Alice registers,the foreign domain can identify Alice's home domain (with its networkbinding) in its name update the home controller.

Referring now to FIG. 4, there is shown network 100 handling seamlessmobility. When Bob is mobile and moves to another PoA, shown as PoA-1,the application (after getting notified) or the ICN layer marks thecontent response with the mobility flag as shown in FIG. 2.

As mobility as a service, ICN layer marking is more appropriate, as theset of content flows which require this support.

The edge routers which receive this content response with this mobilityflag re-resolve FPT entries to its new location.

FIG. 4 depicts Bob/x registering with network 100 through PoA-1, edgerouter R4 of AS-2 domain controller 140. AS-2 domain controller 140creates entry:Bob/x:AS-2→AS-2/PoA-2. The edge node R1 which receivescontent objects with the mobility flag set resolves through the domaincontroller AS-1 supporting Alice holding interest /Bob/x:AS2;AS2/PoA-1.Just before Bob handoffs to PoA-2, Bob begins to respond to the contentresponse by setting the mobility flag.

Mobility as a Service

Mobility is requested from the network only when required as it incurscost (forwarding/control over head etc.). Mobility includes ActiveRegistration/De-registration, and could be enabled at Content, Device,or Service Level.

Mobility Service as Part of the Entity ID:

A mobility_service flag is included as part of the name. This includesmarking the component that is mobile, for e.g., /ravi_device/content/x .. . :M_FLAG:N (means only the 1−N component of the name is mobile). Thisallows the network to handle these interests in a special way.

Decentralized Name Resolution:

Every Organization manages the name space. The Organization-ID is bindedto the name, during mobility service request(I:D). D is the serviceresolution point. /ravi_device/pics/x . . . :M_FLAG:2: att/nrs

Foreign name resolvers update home domain to update locations. Nosynchronization between Name Resolution Service instances, onlynotification.

In-path Re-resolution:

The forwarding-label is modified in-path via name resolution service.The Content response can have the mobility-flag set, and this results inall the service routers to re-resolve the mobile Entity.

Mobility Over a Name Space

Referring to FIG. 5, this illustrates Mobility over a Name Space. Theuser actively registers the name space for which he requires mobility.Then, the Mobility Infrastructure ensures fast name resolution serviceto handle both intra/inter session cases.

The network knows the Mobility Prefix as follows:

During registration or publishing the desired mobile entity, the networkadds its own mobility service tags. So in case of /ravi_device/pics/ . .. :M_FLAG:2, it says the service routers any flows for /ravi_device/picsprefix has to be monitored for mobility.

The Name Resolution Server Synchronization is avoided by binding theName Prefix for e.g. /ravi_device with a Home Domain Name Resolutionservice, hence /ravi_device/pics/x . . . :M_FLAG:1 :att/nrs, hereatt/nrs resolves /ravi_device/pics. This is for new flows from consumersat the Service Routers.

Intra-session mobility is handled by considering there is more than oneconsumer in multiple domains.

The mobility flag is introduced in the content response, as shown inFIG. 2, as the content response traverses all the Service Routers, theycan quickly update their FPT, as they have information of the homedomain.

FIG. 6 illustrates an embodiment of a network unit 1000, which may beany device that transports and processes data through network 100. Forinstance, the network unit 1000 may correspond to or may be located inany of the system nodes described above, such as a MN, PoA, contentrouter R, and AS. The network unit 1000 may also be configured toimplement or support the schemes and methods described above. Thenetwork unit 1000 may comprise one or more ingress ports or units 1010coupled to a receiver (Rx) 1012 for receiving signals and frames/datafrom other network components. The network unit 1000 may comprise acontent aware unit 1020 to determine which network components to sendcontent to. The content aware unit 1020 may be implemented usinghardware, software, or both. The network unit 1000 may also comprise oneor more egress ports or units 1030 coupled to a transmitter (Tx) 1032for transmitting signals and frames/data to the other networkcomponents. The receiver 1012, content aware unit 1020, and transmitter1032 may also be configured to implement at least some of the disclosedschemes and methods above, which may be based on hardware, software, orboth. The components of the network unit 1000 may be arranged as shownin FIG. 6.

The content aware unit 1020 may also comprise a programmable contentforwarding plane block 1028 and one or more storage blocks 1022 that maybe coupled to the programmable content forwarding plane block 1028. Theprogrammable content forwarding plane block 1028 may be configured toimplement content forwarding and processing functions, such as at anapplication layer or L3, where the content may be forwarded based oncontent name or prefix and possibly other content related informationthat maps the content to network traffic. Such mapping information maybe maintained in one or more content tables (e.g., CS, PIT, and FIB) atthe content aware unit 1020 or the network unit 1000. The programmablecontent forwarding plane block 1028 may interpret user requests forcontent and accordingly fetch content, e.g., based on meta-data and/orcontent name (prefix), from the network or other content routers and maystore the content, e.g., temporarily, in the storage blocks 1022. Theprogrammable content forwarding plane block 1028 may then forward thecached content to the user. The programmable content forwarding planeblock 1028 may be implemented using software, hardware, or both and mayoperate above the IP layer or L2.

The storage blocks 1022 may comprise a cache 1024 for temporarilystoring content, such as content that is requested by a subscriber.Additionally, the storage blocks 1022 may comprise a long-term storage1026 for storing content relatively longer, such as content submitted bya publisher. For instance, the cache 1024 and the long-term storage 1026may include Dynamic random-access memories (DRAMs), solid-state drives(SSDs), hard disks, or combinations thereof.

The network components described above may be implemented on anygeneral-purpose network component, such as a computer or networkcomponent with sufficient processing power, memory resources, andnetwork throughput capability to handle the necessary workload placedupon it. FIG. 7 illustrates a typical, general-purpose network component1100 suitable for implementing one or more embodiments of the componentsdisclosed herein. The network component 1100 includes a processor 1102(which may be referred to as a central processor unit or CPU) that is incommunication with memory devices including secondary storage 1104, readonly memory (ROM) 1106, random access memory (RAM) 1108, input/output(I/O) devices 1110, and network connectivity devices 1112. The processor1102 may be implemented as one or more CPU chips, or may be part of oneor more application specific integrated circuits (ASICs).

The secondary storage 1104 is typically comprised of one or more diskdrives or tape drives and is used for non-volatile storage of data andas an over-flow data storage device if RAM 1108 is not large enough tohold all working data. Secondary storage 1104 may be used to storeprograms that are loaded into RAM 1108 when such programs are selectedfor execution. The ROM 1106 is used to store instructions and perhapsdata that are read during program execution. ROM 1106 is a non-volatilememory device that typically has a small memory capacity relative to thelarger memory capacity of secondary storage 1104. The RAM 1108 is usedto store volatile data and perhaps to store instructions. Access to bothROM 1106 and RAM 1108 is typically faster than to secondary storage1104.

It may be advantageous to set forth definitions of certain words andphrases used throughout this patent document. The terms “include” and“comprise,” as well as derivatives thereof, mean inclusion withoutlimitation. The term “or” is inclusive, meaning and/or. The phrases“associated with” and “associated therewith,” as well as derivativesthereof, mean to include, be included within, interconnect with,contain, be contained within, connect to or with, couple to or with, becommunicable with, cooperate with, interleave, juxtapose, be proximateto, be bound to or with, have, have a property of, or the like.

While this disclosure has described certain embodiments and generallyassociated methods, alterations and permutations of these embodimentsand methods will be apparent to those skilled in the art. Accordingly,the above description of example embodiments does not define orconstrain this disclosure. Other changes, substitutions, and alterationsare also possible without departing from the spirit and scope of thisdisclosure, as defined by the following claims.

What is claimed is:
 1. A method for routing a message in a named datanetwork (NDN), comprising: receiving, by a service router, an interestmessage from a consumer node, wherein the interest message is used toexpress interest for a resource, and the interest message includes aname of the resource; obtaining, by the service router, a forwardinglabel according to the name of the resource, wherein the forwardinglabel indicates a location of the resource; and sending, by the servicerouter, an updated interest message to a next hop node in the network,wherein the updated interest message includes a first field containingthe name of the resource and a second field containing the forwardinglabel, and wherein the first field and the second field are two separatefields.
 2. The method of claim 1, wherein before obtaining theforwarding label, the method further comprises: retrieving theforwarding label from a fast path table stored at the service router. 3.The method of claim 1, wherein before obtaining the forwarding label,the method further comprises: sending, by the service router, a requestfor the forwarding label to a local domain controller of the servicerouter.
 4. The method of claim 3, wherein after obtaining the forwardinglabel, the method further comprises: creating, by the service router, alocal entry in a fast path table stored at the service router, whereinthe local entry includes a correspondence between the name of theresource and the forwarding label.
 5. The method of claim 1, wherein theupdated interest message is sent according to a routing policy, whereinthe routing policy includes whether a mobility service flag is includedin the interest message.
 6. The method of claim 1, wherein the methodfurther comprises: synchronizing, by a local domain controller of theproducer node, a correspondence between the name of the resource and theforwarding label with other local domain controllers by introducing amobility flag.
 7. A service router for routing a message in a named datanetwork (NDN), comprising: a processor; and a memory coupled to theprocessor and storing programming for execution by the processor; theprocessor configured to execute the programming to perform operationsof: receiving an interest message from a consumer node, wherein theinterest message is used to express interest for a resource, and theinterest message includes a name of the resource; obtaining a forwardinglabel according to the name of the resource, wherein the forwardinglabel indicates a location of the resource; and sending an updatedinterest message to a next hop node, wherein the updated interestmessage includes a first field containing the name of the resource and asecond field containing the forwarding label, and wherein the firstfield and the second field are two separate fields.
 8. The servicerouter of claim 7, wherein the processor is configured to execute theprogramming to perform an operation of: retrieving the forwarding labelfrom a fast path table stored at the service router.
 9. The servicerouter of claim 7, wherein the processor is configured to execute theprogramming to perform an operation of: sending a request for theforwarding label to a local domain controller of the service router. 10.The service router of claim 9, wherein the processor is configured toexecute the programming to perform an operation of: creating a localentry in a fast path table stored at the service router, wherein thelocal entry includes a correspondence between the name of the resourceand the forwarding label.
 11. The service router of claim 7, wherein theprocessor is configured to execute the programming to perform anoperation of: updating a correspondence between the name of the resourceand the forwarding label to a local domain controller in responsive to amobility service flag indicating a mobility of the resource's producernode.
 12. A system configured for routing a message in a named datanetwork (NDN), comprising: a first service router configured to receivea registration message from a producer node, wherein the producer nodeprovides access to a resource, and the first service router furtherconfigured to register the resource to a local domain controller; and asecond service router configured to: receive an interest message from aconsumer node, wherein the interest message indicates interest for theresource, and the interest message includes a name of the resource,obtain a first forwarding label according to the name of the resource,wherein the first forwarding label indicates a location of the resource;and send an updated interest message to a next hop node in the NDNnetwork, wherein the updated interest message includes a first fieldcontaining the name of the resource and a second field containing thefirst forwarding label, and wherein the first field and the second fieldare two separate fields.
 13. The system of claim 12, wherein a header ofthe updated interest message includes the first field and the secondfield.
 14. The system of claim 12, wherein the system further comprisesan intermediate destination point configured to swap the firstforwarding label to a second forwarding label after resolution orthrough a fast pass table (FPT) look-up.
 15. The system of claim 12,wherein the local domain controller further configured to create a localentry, wherein the local entry includes a correspondence between thename of the resource and the first forwarding label.
 16. The system ofclaim 12, wherein the system comprises a multiple of domains, eachdomain has a local domain controller, and wherein the local domaincontroller of the producer node is configured to synchronize acorrespondence between the name of the resource and a second forwardinglabel with other local domain controllers.
 17. The system of claim 16,wherein the system comprises an edge service node, the edge service nodeis configured to introduce a mobility flag to the resource tosynchronize the correspondence between the name of the resource and thesecond forwarding label.
 18. The system of claim 12, the second servicerouter configured to send the interest message according to a routingpolicy, wherein the routing policy includes whether a mobility serviceflag is included in the interest message.
 19. The system of claim 12,wherein the name of the resource comprises a mobility service flagindicative of use to a mobility resolution infrastructure.
 20. Thesystem of claim 19, wherein the mobility service flag is indicative ofthe producer node that is mobile.